1. Plan
-
Généralités
-
Survol global de SysML
-
Spécificités
-
Etude de cas d’un robot Rover en partenariat avec eclipse
2. Qui suis-je ?
-
Professeur à l’Univesité de Toulouse
-
Co-fondateur de l’association SysML-France
-
Membre du comité éditorial de la revue SoSyM
-
Membre du Steering Committee de la conférence ACM/IEEE MODELS
-
Co-responsable de l’axe Systèmes Ambiants de l’IRIT
-
Enseigne la modélisation depuis 1995 et SysML™ depuis 2008
3. Objectifs et attentes
-
Formation à SysML "pour novices"
-
Développer une étude de cas complet
-
Vous préparer au défi SysML-France de la Nuit de l’Info ;-)
|
|
|
4. C’est quoi SysML?
Si vous voulez partir (ou lire vos emails) dans 5 minutes…
5. Fiche d’identité
|
|
Version beta de la 1.4 disponible depuis avril 2014. |
6. SysML, c’est…
- Un ensemble de 9 types de diagrammes
-
-
Diagrammes structuraux
-
Diagrammes de définition de blocs (
bdd) -
Diagrammes internes de blocs (
ibd) -
Diagrammes paramétriques (
par) -
Diagrammes de packages (
pkg)
-
-
Diagrammes comportementaux
-
Diagrammes de séquence (
sd) -
Diagrammes d’activité (
act) -
Diagrammes de cas d’utilisation (
uc) -
Diagrammes d’états (
stm)
-
-
Diagramme d’exigence (
req)
-
- Un profil UML™
-
C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML™. Un exemple : le
blocSysML™ n’est qu’une redéfinition de laclasseUML™. - Une notation
-
Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.
7. SysML, ce n’est pas…
- Une méthode
-
En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML™ ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.
- Un outil
-
Nous verrons en effet que SysML™ ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.
- Un raton laveur
-
C’est juste pour voir ceux qui suivent.
|
|
On ne dit pas "le SysML" mais tout simplement "SysML". |
8. Pourquoi une nouvelle notation
A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.
The World of Mathematics (1956)
Il existe une notation qui se veut "unifiée" pour les modèles : UML™.
Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :
-
UML 1.x était complètement inadaptée :
-
Principalement pour les systèmes d’information
-
Peu de liens entre les diagrammes
-
Peu de liens entre les modèles et les exigences
-
-
UML 2.x n’est pas beaucoup mieux si ce n’est :
-
Implication des ingénieurs systèmes pour sa définition
-
Introduction du diagramme de structure composite
-
En conclusion UML™ est une bonne base :
-
Standard De facto en génie logiciel
-
Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)
-
Stable et extensible (grâce notamment au mécanisme de profile)
-
Beaucoup d’outils disponibles
Mais…
-
Manque de certains concepts clés d’Ingénierie Système
-
Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de
classeou d'`héritage` par exemple) -
Trop de diagrammes (13 sortes)
9. Introduction à SysML
10. Différence avec UML
11. Qui est "derrière"?
- Industrie
-
American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …
- Vendeurs d’outils
-
Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …
- Autres organisations
-
AP-233, INCOSE, Georgia Institute of Technology, AFIS, …
|
|
La liste complète des membres de l’OMG™ est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl |
12. Organisation des différents diagrammes
|
|
Définition : Types de diagrammes (OMG SysML v1.3, p. 170)
SysML diagram kinds should have the following names or (abbreviations) as part of the heading… |
13. Outils SysML
Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :
Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.
Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d’éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.
|
|
Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation. |
14. Cadre pour les diagrammes
Abordons quelques principes généraux de SysML™, c’est à dire des éléments indépendant d’un diagramme en particulier :
-
Chaque diagramme SysML™ décrit un élément précis (nommé) de modélisation
-
Chaque diagramme SysML™ doit être représenté à l’intérieur d’un cadre (Diagram Frame)
-
L’entête du cadre, appelé aussi cartouche, indique les informations sur le diagramme :
-
le type de diagramme (
req,act,bdd,ibd,stm, etc. en gras) qui donne immédiatement une indication sur le point de vue porté à l’élément de modélisation (comportement, structure, etc.) -
le type de l’élément (par exemple package, block, activity, etc.), optionnel
-
le nom de l’élément (unique)
-
le nom du diagramme ou de la vue, optionnel
-
15. Le Package Diagram
Le diagramme de paquetage permet de représenter l'organisation des modèles en paquetages.
-
Il est identique à UML™, et classique pour les développeurs (java notamment)
-
Il permet d’organiser les modèles en créant un espace de nommage
16. Les organisations possibles
Les modèles peuvent être organisés selon toutes sortes de considération :
-
par hiérarchie "système" (e.g., entreprise, système, composant, …)
-
par types de diagrammes (e.g., besoins, structure, comportements, …)
-
par cycle de vie (e.g., analyse, conception, …)
-
par équipes (e.g., architectes, [IPT], …)
-
par points de vue (e.g., sécurité, performance, …)
-
etc.
T, UK)T, UK)T, UK)T, UK)17. Les exigences
18. Représentation de base
Un Requirement en SysML™ n’est qu’un bloc particulier.
P)19. Tableaux de Requirements
Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.
|
|
Définition : Requirements Table (OMG SysML v1.3, p. 145)
The tabular format is used to represent the requirements, their properties and relationships… |
20. Liens avec les outils
21. Les Requirements properties
Il est possible d’indiquer un certain nombre de propriétés sur un requirement :
-
priority (
high,low, …) -
source (
stakeholder,law,technical, …) -
risk (
high,low, …) -
status (
proposed,aproved, …) -
verification method (
analysis,tests, …)
22. Les Requirements links
Les principales relations entre requirement sont :
- Containment
-
Pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–). Typiquement dès qu’une exigence est exprimée avec une conjonction "et" ("La voiture doit être rapide et économe.").
- Refinement
-
Pour décrire un ajout de précision (
[refine]), comme par exemple une précision. - Derivation
-
Pour indiquer une différence de niveau d’abstraction (
[deriveReqt]), par exemple entre un système et un de ses sous-systèmes.
23. Les Requirements links (suite)
Il existe ensuite les relations entre les besoins et les autres éléments de modélisation
(les block principalement) comme [satisfy] ou [verify], mais nous les aborderons
dans la partie transverse.
24. Les Requirements Diagrams
Voici un exemple de req un peu plus étoffé, tiré de la norme (voir aussi [rationale]) :
26. L’architecture du système
On abordera :
-
l’organisation du système et des modèles
-
les Block Definition Diagrams
-
les Internal Block Diagrams
-
les Parametric Diagrams (pour les contraintes physiques)
-
les Sequence Diagrams (diagramme de séquence système)
27. Block Definition Diagrams
28. Propriétés
On peut différencier 4 types de propriétés d’un bloc :
- value properties
-
Des caractéristiques (quantifiables), aussi appelées simplement values
- parts
-
Les éléments qui composent le bloc (cf. Internal Block Diagrams)
- references
-
Les éléments auquel le bloc a accès (via des associations ou des agrégations)
- constraint properties
-
Les contraintes que doivent respecter les propriétés (nous les verrons plus en détail, cf. Parametric Diagrams).
|
|
Les values sont ce qui se rapproche le plus des attributs de classes UML. |
29. Associations entre blocs
Il existe deux types de relations entre blocs :
-
l’association (y compris l’agrégation et la composition)
-
la généralisation/spécialisation
30. Internal Block Diagrams
Un ibd décrit la structure interne d’un bloc sous forme de :
- parts
-
Les parties qui constituent le système (ses sous-systèmes)
- ports
-
Elément d’interaction avec un bloc
- connecteurs
-
Liens entre ports
31. Parts
32. Ports (SysML 1.2)
33. Ports (SysML 1.3)
La nouvelle spécification OMG SysML v1.3 introduit les concepts de:
- proxy port
-
Ils doivent remplacer les ports 1.2 (ports de flots et ports standards) en en reprenant les caractéristiques et en ajoutant la possibilité d’imbrication et de spécification renforcée.
- full port
-
En fait il s’agit du même concept qu’une partie qui serait exposée à l’extérieur.
|
|
Pour une discussion sur les différences entre les deux ports : http://model-based-systems-engineering.com/2013/09/23/sysml-full-ports-versus-proxy-ports/ |
34. Parametric Diagrams
Afin de capturer de manière précise les contraintes entre valeurs, ou encore les liens entre les sorties et les entrées d’un bloc, SysML™ utilise trois concepts clefs :
-
Constraints (un type de bloc)
-
Parametric diagram (un type d'`ibd`)
-
Value binding
35. Contraintes
C’est un bloc particulier :
-
avec un stéréotype
≪constraint≫(au lieu de≪block≫) -
des paramètres en guise d’attributs
-
des relations liant (contraignant) ces paramètres
36. Diagramme paramétrique
C’est une forme particulière de Internal Block Definition
38. Le comportement du système
39. Le Diagramme des Cas d’Utilisation
Le Diagramme des Cas d’Utilisation est un diagramme UML™ permettant de représenter :
-
les UC (Use Case ou Cas d’Utilisation)
-
les acteurs (principaux et secondaires)
-
les relations
-
entre acteurs et Use Case
-
entre Use Cases
-
40. Cas d’Utilisation (Use Case)
Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.
41. Sequence Diagrams
42. Généralités
Il permet de :
-
modéliser les interactions entre blocs
-
séquencer ces interactions dans le temps
-
représenter les échanges de messages
-
spécifier les scénarios des cas d’études
43. Diagrammes de séquence système
44. Exemple
45. Notions avancées
On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :
-
loop(boucle) -
alt(alternative) -
opt(optionel) -
par(parallèle) -
region(région critique - un seul thread à la fois)
46. Lien entre UC, DSS et DS
La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.
On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.
Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocs composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.
47. Diagramme d’états
48. Diagrammes d’activité
49. Diagramme paramétrique
50. Génération de documentation
La plupart des outils permettent de générer de la documentation. Pour les outils basés eclipse
il est possible d’utiliser le plug-in GenDoc2.
52. Génération de documentation
Les outils commerciaux comme Rhapsody permettent de générer de nombreux formats.